It is important to agree on Quality Gate Process and governance for the in scope projects together with agreeing the approach to dealing with any variance to agreed plans.

Setting up the organization and processes and procedures for on-going project work is the responsibility of the Service Delivery Processes and the Service Engagement Initiation streams. The WIP Lead will need to work closely with those streams.

Typically, this is not a one off activity; since anytime during the service transition the Client may initiate a new piece of work.

Define mechanics for handling projects that go live before handover

These projects may not have been included in the scope and ‘Run’ costs for the engagement.

Consider their impact and liaise with the Transition Lead and Service Engagement Initiation stream:

• Agree with the Client, incumbent and other relevant service provider(s) as appropriate), what projects should be assessed, how they should be assessed and how they should be monitored (e.g. weekly or monthly progress reports)
• Outline the purpose of the service impact assessment which should be carried out for each project
• Agree which projects Capgemini must audit and what should be assessed (e.g. that the items our Service Impact Assessment will assume are valid)
• Agree the frequency of monitoring each agreed project before implementation and the monitoring of its impact afterwards.

Define mechanics for handling projects that Capgemini are to complete

Projects that fall into this area can be where there are staff transfers - so the same people who complete the project are those who started it, just under different management. It is becoming more common for these projects to not include staff transfers so a careful assessment and analysis should be required.

These projects may not have been included in the scope and ‘Run’ costs for the engagement.

Consider their impact and liaise with the Transition Lead and the Service Engagement Initiation stream:

• Agree with the Client, incumbent and other relevant service provider(s) (as appropriate), what projects should be assessed, how they will be assessed and how they should be monitored (e.g. weekly or monthly progress reports)
• Outline the purpose of the service impact assessment which should be carried out for each agreed project
• Agree which projects Capgemini will audit and what should be assessed (e.g. that the items our Service Impact Assessment will assume are valid)
• Agree whether Capgemini should complete the project on time and materials (T&M) or fixed price basis, and at what stage this estimate and price shall be produced
• Agree what mechanics must be used to pass over completion responsibilities.

Define mechanics for handling projects that the Client, incumbent or other service provider(s) should complete (post service handover)

These projects may not have been included in the scope and ‘Run’ costs for the engagement. Consider their impact and liaise with the Transition Lead and the Service Engagement Initiation stream.

This is a key step, since the mechanics that are defined here feed into the Service Delivery Processes stream:

• Review and revise standard Quality Gate Process according to the Client specific environment (e.g. what Client policies need to be referenced; Capgemini standard Quality Gate Process/service introduction documentation deliverables typically tie into the linear application development lifecycle – this may need tuning for the predominant development lifecycle of the Client – including the Gate ‘A’ ready to go-live and Gate ‘B’ stable approach)
• Agree what level of education is required in the Quality Gate Process and where Capgemini has the contractual responsibility for this, educate as appropriate
• Establish the specific changes necessary to the individual WIP projects to comply with the Quality Gate Process- this may well involve the Client going back to the incumbent or other service provider(s) with change control to include Capgemini for acceptance criteria sign-off on certain deliverables and may take away certain roles that Capgemini must control post service handover (e.g. configuration management).

In addition there may be projects that transition is dependent on or are dependent on transition. Confirm how these should be dealt with. Typically this should be set out in the contract.

The WIP Lead must subsequently prepare a Responsibility Matrix For In-Scope Projects to confirm activities and gating for the projects in scope for Capgemini. The WIP Lead must work closely with the Service Delivery Processes and the Service Engagement Initiation streams.

Responsibility for creating the overall Responsibility Matrix For In-Scope Projects and governance should be dependent on the scope of the contract and the number of stakeholders. For example if it is a service integration or multi-tower contract, then the service integrator or Client may take the lead.

•  Update the WIP Projects Inventory with all of the relevant information gathered
•  Update the Service Engagement Risk Log and Service Engagement Issue Log as appropriate.